Fix DTMF deduplication to use (timestamp, event code) composite key - #796

Problem

The DTMF handler in dtmfHandler (media_port.go) deduplicated incoming DTMF packets using only the RTP timestamp:

if h.Timestamp == p.lastDTMFTimestamp.Load() {
    return nil
}

RFC 4733 requires all packets of a given digit to share identical timestamps, so this correctly filters redundant packets within one digit. However, some SIP devices or carriers reuse the timestamp of the previous digit when sending the next digit. When this happens, the next digit is incorrectly filtered out and never reported.

Fix

Replace the timestamp-only dedup with a (timestamp, event code) composite key:

ev, err := dtmf.Decode(payload)
if err != nil {
    return nil
}
eventID := uint64(h.Timestamp)<<8 | uint64(ev.Code)
if eventID == p.lastDTMFEvent.Load() {
    return nil
}
p.lastDTMFEvent.Store(eventID)
fnc(ev)

Behavior

Known limitation

If an upstream sends two identical digits (e.g. two 0s) with the exact same timestamp and event code, the (timestamp, event code) key alone cannot distinguish them. Resolving that case requires full DTMF lifecycle state tracking (marker bit, End bit, duration reset, sequence number gaps). That is a more complex enhancement beyond this fix; in the worst case (all fields identical) the receiver cannot distinguish the digits at all.

Changes

• pkg/sip/media_port.go: Replace lastDTMFTimestamp atomic.Uint32 with lastDTMFEvent atomic.Uint64; update dtmfHandler to decode first, then dedup on composite key.
• pkg/sip/media_port_test.go: Update field reference; add TestMediaPortDTMFSameTimestamp verifying two different digits (0 and 1) sharing the same RTP timestamp are both reported.

Test plan

• TestMediaPortDTMF — all 12 existing subtests pass (digits 1/12/123 × loss none/first/last/middle)
• TestMediaPortDTMFSameTimestamp — new test passes: digits 0 and 1 with same timestamp → both reported as 01